fix(profiles): say why a profile save failed without the server's text - #3098

Profile Settings printed reason.message, so a failed save showed the
server's "internal error", a relay restriction such as "restricted: you
are timed out until 1794600000", or a JSON parser error when a proxy
answered with an HTML page.

communityRequest now checks response.ok before parsing, on both hosts.
A non-transient failure throws CommunityRefused (the status plus the
bounded refusal reason), the relay's OK false becomes PublishRejected,
and an unconfirmed publication is ReadError("invalid-response").
Callers that match on the message keep working.

Profile Settings maps the failure by where the save stopped:
- not sent, 5xx or unknown: "Couldn’t save your profile. Try again."
  (Save stays enabled)
- refused: "This community didn’t accept your profile change." plus a
  known reason
- not confirmed: "Buzz couldn’t confirm your profile was saved. Save
  again to check." (it said "Your profile change is not current. Your
  edits are retained; save again to retry.")

The shared refusal reason for "restricted: you are timed out until
<ts>" now reads "You’re rate limited until Nov 13, 8:00 PM." (or
"You’re rate limited." without a readable end) instead of "You’re timed
out until …".

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: mtoohey <mtoohey@squareup.com>

…the relay's words

Add userCopy(error, context) in features/relay. It classifies a failure
by the typed errors Buzz already produces (ReadError kind and status,
ApiPaused/ApiCapacity, UploadError, PublishRejected/PublishNotSent,
fetch's network TypeErrors, DOMException names) and returns { text,
retry, kind, details }. text is the site's own sentence plus a plain
next step and never carries an exception name, HTTP status, URL or raw
relay or native string; those stay in details. ErrorDetails renders
details under a collapsed "Details" disclosure.

The relay layer keeps failures typed instead of stringified:
- The service snapshot stores a RelayFailure ({ kind, details }) and
  channel windows and thread snapshots keep a WindowFailure. History
  parse failures are ReadError("invalid-response").
- The window store records errorSource "older" only when loadOlder
  failed, so a head or catch-up failure no longer blames older history.
- PublishNotSent carries the relay's wait for a quota hint or a held
  lane, so busy copy can say how long.
- Copy and retry share one set of fetch network messages (including
  WebKit's), and a body cut off after its headers is an unavailable read.
- An answer Buzz can't use is not retried at once. The service asks
  again in the background after 30 s, 1, 2 and every 5 minutes, keeping
  the failure on screen meanwhile.

History reads: ChannelBody, ChannelTimeline, NewMessage, ThreadPanel,
MediaReviewViewer and DraftPreview map the failure with historyFailure():
"Messages didn’t load." with "Try again" for an outage or 5xx; "Buzz is
busy. Try again in a few seconds." (or "in about N minutes/hours") when
paused; "Check for updates" and no Try again for a 4xx or invalid
answer; "You don’t have access to this conversation." for a refusal with
no known reason. The older edge says "Older messages didn’t load.".

Connection failures: Workflows and Notes show the Messages
ConnectionFailed card: "Can’t connect", "Check your connection. We’ll
keep trying." and "Try again".
An answer Buzz can't use reads "Buzz couldn’t connect to this
community." with "Check for updates"; a refusal shows the community
refusal title with no retry. Bestie, Pinned Bestie, Activity, its
preview and Reminders say the same through connectionFailureText and
connectionFailureAction. App's page failure cards put the primary
action last and drop Try again for an unusable connection.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: mtoohey <mtoohey@squareup.com>

Five journeys still asserted the copy that the previous commit replaced:

- thread-window: the older-replies alert said "Older page failed"; it now
  says "Older replies didn’t load." (ThreadPanel's OlderRepliesFailure).
- media-controls, message-overlays, gallery-theme: MediaReviewViewer's
  unavailable-media button was "Retry"; it is "Try again". The
  message-overlays title and the gallery comment follow the rename.
- navigation-repairs: the keyboard hand-off journey failed the session
  with an empty JSON object. That is now an answer Buzz can't use, so
  the card says "Buzz couldn’t connect to this community." and offers
  Check for updates, not Try again. The journey now fails the broker
  registration with a recorded 502 instead, a failure the service leaves
  for the user, so the card still says "Check your connection, then try
  again." and offers Try again. Every caller registers the community, so
  every registration fails until the user acts, and the retry is counted
  from then on.

Product copy is unchanged.

Signed-off-by: Matt Toohey <contact@matttoohey.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>